從「盯著鍋子看」到「看儀表板」

想像你是一位傳統煉金師，站在熊熊燃燒的煉金爐前。你怎麼知道配方煉得好不好？

傳統方式：

• 用眼睛盯著火焰顏色（太紅？太藍？）
• 用鼻子聞氣味（有沒有燒焦味？）
• 用手感受溫度（好像有點燙？）
• 憑經驗判斷（差不多快好了吧？）

這種方式有什麼問題？你得一直站在爐子旁邊。離開五分鐘，可能整鍋就燒焦了。而且全憑主觀感覺，今天狀態好就成功，狀態不好就失敗。

現代煉金師：
裝上一個儀表板，上面顯示：

• 爐溫：752°C（理想範圍 750-800°C）
• 壓力：1.2 bar（正常）
• 反應時間：45 分鐘 / 60 分鐘
• 成本：$12.50 / 預算 $15.00

一眼就知道：「很好，一切正常，我可以去喝杯咖啡了。」

這就是 Metrics (指標) 的威力。

三個好朋友的分工：誰負責什麼？

經過三天的學習，我們終於集齊了可觀測性的三位好朋友。讓我們總結一下他們的分工：

Logs (Day 24)：事後調查的偵探

• 角色：「到底發生了什麼事？」
• 時機：問題發生後，回頭調查
• 比喻：法醫的驗屍報告，詳細但要花時間翻閱

使用場景：

老闆：「為什麼昨天下午 3 點客戶抱怨 AI 給出錯誤答案？」
你：「讓我查一下日誌...」
（翻找 10 分鐘）
你：「找到了！RAG 檢索到過期的文件。」

Traces (Day 25)：追蹤路徑的物流司機

• 角色：「這個請求走了什麼路徑？」
• 時機：想了解整個流程，或找出瓶頸
• 比喻：包裹追蹤系統，知道每個環節花了多久

使用場景：

老闆：「為什麼這個功能這麼慢？」
你：「讓我看一下 Trace...」
（分析路徑）
你：「找到了！RAG 檢索那一步花了 8 秒，因為沒有建立索引。」

Metrics (Day 26)：即時監控的儀表板

• 角色：「現在系統健不健康？」
• 時機：即時監控，問題發生前就發現
• 比喻：汽車儀表板，一眼就知道狀況

使用場景：

老闆：「系統現在正常嗎？」
你：「正常！」（看了一眼儀表板）
「回應時間 1.2 秒，錯誤率 0.1%，成本在預算內。」

重點來了：Metrics 是唯一能讓你「不用等問題發生」就知道狀況的工具。

AI 系統的四大生命指標

還記得 Day 20 我們聊過 TTFT 和 TPS 嗎？那是回應速度的指標。但一個健康的 AI 系統需要監控的遠不止速度。

就像醫生檢查病人，不會只量體溫，還要量血壓、心跳、血氧。AI 系統也需要「四大生命指標」。

指標一：效能指標 (Performance Metrics)

核心問題：系統夠快嗎？

- 平均回應時間 (Latency)：1.2 秒
- P95 回應時間：2.5 秒（95% 的請求在此之內）
- P99 回應時間：5.0 秒（99% 的請求在此之內）
- TTFT (首字回應時間)：450 毫秒
- TPS (每秒生成字數)：25.3 tokens/s

為什麼要 P95、P99？
想像你是餐廳老闆：

• 平均出餐時間 5 分鐘（看起來不錯）
• 但 5% 的客人要等 30 分鐘（這些人會氣炸）

P95、P99 就是找出那些「倒楣的少數」，確保他們也有好體驗。

指標二：品質指標 (Quality Metrics)

核心問題：回答正確嗎？使用者滿意嗎？

- 成功率：98.5%（請求成功完成的比例）
- 錯誤率：1.5%（請求失敗的比例）
- Guardrail 攔截率：0.8%（Day 17-19 的安全護欄觸發次數）
- 使用者滿意度：4.2 / 5.0（需要實作評分系統）
- 重試率：5%（使用者點「重新生成」的比例）
- 使用者回饋率：2%（主動標記「有幫助」或「沒幫助」）

自動 vs 手動收集：
品質指標可分為兩類：

• 系統自動收集：成功率、錯誤率、Guardrail 攔截率、重試率（只需埋點追蹤）
• 需要使用者互動：滿意度、回饋率（需要在應用中實作按讚/倒讚、評分系統等收集機制）

Day 7 的 RAG 和 Day 17-19 的 Guardrails 都可以提供間接的品質指標，例如檢索相關性、安全過濾觸發次數等。

指標三：成本指標 (Cost Metrics)

核心問題：燒錢速度如何？

- 每日總成本：$127.50
- 每請求平均成本：$0.05
- Token 使用量：2.5M tokens/day
- 快取命中率：65%（Day 21 的 Prompt Caching）
- 最貴的功能：客戶分析報告（$0.25/次）

還記得 Day 22 的成本優化嗎？這些指標告訴你優化是否有效。

指標四：健康指標 (Health Metrics)

核心問題：系統的基礎設施健康嗎？

- 可用性 (Uptime)：99.95%
- API 配額使用率：45% / 100%
- 記憶體使用率：62%
- 並發請求數：125（峰值 500）
- 佇列長度：8 個請求在等待

從數字到警報：讓儀表板會說話

光有數字還不夠，重要的是「什麼時候該緊張」。

就像體溫計，不會只顯示「37.5°C」，還會告訴你：

• 綠燈：正常範圍
• 黃燈：有點高，要注意
• 紅燈：發燒了，趕快看醫生！

三色警報系統

綠燈 (Green)：一切正常

平均回應時間：1.2 秒 (正常，目標 < 2 秒)
錯誤率：0.5% (正常，目標 < 1%)
每日成本：$85 (正常，預算 $150)

黃燈 (Yellow)：需要注意

P95 回應時間：2.8 秒 (警告，目標 < 2.5 秒)
佇列長度：45 個 (警告，正常 < 20)
快取命中率：52% (警告，目標 > 60%)

紅燈 (Red)：立刻處理

錯誤率：15% (嚴重，目標 < 1%)
每日成本：$250 (超標，預算 $150)
可用性：95% (嚴重，目標 > 99%)

智慧警報：不要讓人崩潰

還記得 Day 23 的半夜三點惡夢嗎？如果警報系統設計不好，你會被「假警報」煩死。

爛警報系統：

03:15 [警告] 回應時間 2.1 秒（超過 2 秒）
03:16 [警告] 回應時間 1.9 秒（恢復正常）
03:17 [警告] 回應時間 2.2 秒（超過 2 秒）

→ 你：「到底有沒有問題啊！！！」（崩潰）

聰明警報系統：

03:15 [注意] 回應時間開始波動（最近 5 分鐘平均 2.1 秒）
03:20 [警告] 回應時間持續偏高（最近 10 分鐘平均 2.3 秒）
03:25 [緊急] 回應時間嚴重超標（最近 15 分鐘平均 3.5 秒）

→ 你：「確實有問題，而且越來越嚴重，該起床修了。」

設計原則：

1. 時間窗口：看趨勢，不看單點（例如「5 分鐘平均」而非「單次請求」）
2. 多級警報：注意 → 警告 → 緊急，給你反應時間
3. 自動恢復：問題解決後自動解除警報

如何串聯前面 25 天的學習？

Metrics 不是孤立存在的，它是整個系統的「健康總覽」：

• Day 7 的 RAG：監控檢索品質、快取命中率、發現瓶頸
• Day 9 的 Context 管理：監控 Token 使用量、評估壓縮策略效果
• Day 14-16 的 Multi-Agent：拆解每個 Agent 效能、找出最慢環節
• Day 21 的 Prompt Caching：追蹤快取命中率、計算成本節省
• Day 22 的成本優化：即時追蹤成本、預警超支風險
• Day 24-25 的 Logging + Tracing：Metrics 發現異常 → Tracing 定位位置 → Logging 找出原因

從賭徒到科學家：資料驅動的決策

還記得 Day 1 我們說過「從賭徒到煉金師」嗎？現在，我們要再進化一次：從煉金師到科學家。

賭徒時代（Day 1）：

• 「這次不行？再試一次！」
• 碰運氣，沒有方法

煉金師時代（Day 2-25）：

• 「我知道怎麼調配方！」
• 有方法，但憑經驗

科學家時代（Day 26）：

• 「資料告訴我該怎麼做！」
• 用資料驗證，持續改進

Metrics 讓你能做到：

1. A/B 測試：新版 Prompt 真的比較好嗎？看資料
2. 效能優化：這個優化有效嗎？看資料
3. 成本控制：錢花在哪裡？看資料
4. 容量規劃：需要擴展嗎？看資料

不是憑感覺說「好像比較好」，而是用數字證明「確實更好」。

從黑盒子到玻璃屋

經過 26 天的修練，你的 AI 系統不再是神秘的黑盒子，而是一個透明、可控、可預測的智慧工房。
儀表板上的每個數字，都在訴說著系統的故事。
而你，已經學會了如何傾聽、如何理解、如何行動。